In recent years, there has been increasing movement away from traditional on-premises computer networks toward cloud-based or virtual computer networks. Use of virtual machines, containers, and even serverless code has proliferated and become an integral part of IT infrastructure for all types of businesses, government agencies, and educational institutions. Through platform offerings such as Software-as-a-Service (SaaS), Infrastructure-as-a-Service (IaaS), and Platform-as-a-Service (PaaS), enterprises and other institutions are able to remotely store, process, and access data and software to run their operations.
At the same time, efficient and flexible development and deployment processes for software have become increasingly popular. Practices such as DevOps, continuous integration, and continuous deployment have been more prevalently used by enterprises and other entities to shorten the time between code changes and code deployment, resulting in more agile and optimized software products and services. Many of these practices are integrated into cloud-based, virtual computing environments.
The expanding use of virtualized computing frameworks presents significant security risks. From the perspective of the enterprise using a virtualized network, there are risks that their applications may be wrongfully accessed, modified, or used. Examples include privilege escalation attacks, denial of service attacks, corporate espionage, and others. From the cloud host's perspective, additional risks include attackers escalating privileges such that they can gain access to the host system itself or access sensitive data (e.g., data available on the host system or externally). When an attacker can, for example, “escape” from a virtual machine or container and penetrate the underlying host system, the attacker can potentially cause widespread damage throughout the entire host system, potentially affecting numerous enterprises using the host for cloud services. From the perspective of individuals and entities having sensitive or confidential data stored in the cloud, additional risks are that their data may be improperly accessed, improperly shared, or improperly deleted.
Additional vulnerabilities arise when identities (e.g., human users, applications, etc.) need to access a running virtual computing instance, such as a database, server, storage device, application, or another identity. This may happen, for example, when IT personnel or website developers need to access running and operational instances, or when automated or machine-based processes attempt to access instances as part of their functionality (e.g., backups, debugging, DevOps, file fixes or changes, database maintenance, process restarting, content editing, software updates, etc.). When access to running and operational virtual instances is performed, the access is often provided via a command such as “docker exec” or “docker cp,” which are run on a host (e.g., a host deploying the virtual instances). Running such commands on a host can cause security dangers. Allowing identities to access a host system (e.g., via an SSH connection or other secure connection) in these manners involves access to the host daemon (e.g., a Docker™ daemon), which is equivalent to accessing root privileges on the host system. With this deep level of access to the host, an identity can perform various security-sensitive actions, such as instantiating new virtual instances (some of which may be privileged instances), accessing existing instances (some of which may also be privileged), or even taking over control of the host system itself.
For these reasons, current industry practices counsel against allowing access to running and operational virtual instances. Instead, conventional practices use immutable virtual instances. Once virtual instances are spun up, they should not be accessed. Nevertheless, this leads to many practical problems in terms of system operations. If security policies forbid accessing a running virtual instance, other identities may be unable to perform their functionality if they need to access the instance. Similarly, the instance itself may be severely limited in its functionality and usefulness if access to it is restricted.
Accordingly, in view of the significant security vulnerabilities that arise with the growing popularity of cloud-based services, technological solutions are needed for addressing the ability of users or applications to “escape” from permitted virtualized and isolated instances, and improperly penetrate host systems and other virtualized environments served by the host systems. Technological solutions are needed for identifying privileged virtual instances, which have parameters or configurations (e.g., based on flags, permissions, credentials, etc.) giving them privileged access sufficient to access an underlying host system. Existing approaches, which attempt to identify malicious communications and actions of virtual instances, are insufficient because they are unable to detect privileged virtual instances before malicious activity occurs. Such techniques are powerless to detect risks that virtual instances will exploit an underlying host system and/or other privileged instances being supported by the host system.
As described herein, technological solutions are needed to identify the attempted creation of privileged virtual instances, before they are able to penetrate host systems and cause harm to the host or other cloud-based entities served by the host. Additionally, technological solutions are needed for controlling the creation, deployment, and operations of virtual instances that may have, or may obtain, privileged capabilities. As described further below, investigative and predictive processes may be used to determine whether a virtual instance is to be deployed with privileged capabilities, or may gain such capabilities in the future. For such privileged instances, controls are provided for preventing the deployment of the instances, limiting their capabilities to remove privilege escalation risks, generating alerts or reports, or generating prompts requiring authentication (e.g., single-factor, two-factor, etc.) or authorization (e.g., from a manager, administrator, etc.).
Additionally, technological solutions are needed for enrolling newly instantiated virtual instances and managing secure access to them from identities. As discussed in greater detail below, when a privilege level or score for a newly spun up instance is determined, that level or score may advantageously be used to determine whether to automatically enroll the instance and permit access to it. For instances posing low privilege threats (e.g., non-privileged instances), a cryptographic key may be provisioned to the instance for use in later verifying a signature asserted by an identity requesting access to the instance. For example, an identity may receive a private/public key pair, which may be signed in a manner where the instance can verify the signature using the key it received. Upon a successful signature verification, a secure session (e.g., SSH session, etc.) may be established between the requesting identity and the instance. For newly spun up instances that are determined to pose privilege risks, automatic enrollment may be declined, and instead additional security review may be applied.